System and method for selecting a best-fit form or URL in an originating web page as a target URL for replaying a predefined path through the internet

ABSTRACT

A system and method for replaying a predefined path through a set of web pages. The system and method comprises selecting in chronological order a saved request in a request history. The saved requests correspond to a set of user requests made at a web page from the set of web pages. Furthermore, the present invention comprises determining whether the saved request is a form request, and if so finding a best fit form on the web page from the set of web pages and sending a replay request to the best-fit form. If the saved request is not a form request, making the replay request to a best-fit URL.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of, and claims a benefit of priorityunder 35 U.S.C. 120 to, the filing date of U.S. patent application Ser.No. 09/710,212 by inventors Clay Davis, Walter R. Bodwell and Michael C.Klobe entitled “System and Method for Replaying a Predefined PathThrough the Internet” filed on Nov. 10, 2000, now U.S. Pat. No.6,901,438 which in turn claims priority under 35 U.S.C. 119(e) toprovisional application number 60/165,103 filed Nov. 12, 1999 entitled“System and Method for Software Simulation of A User Following A PathThrough a Web Site, and provisional application number 60/165,102 filedNov. 12, 1999, entitled “System and Method for Routing a User Through anIntermediate Web Server”, the entire contents of which are herebyexpressly incorporated by reference for all purposes.

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to web page systems and methods,and more particularly, a software system and method for replaying apredetermined web path from an intermediate server.

BACKGROUND OF THE INVENTION

As web sites become more ubiquitous, businesses are increasinglyinterested in setting performance goals and quality standards for theirweb sites. One way to achieve these objectives is to simulate a user'sexperience with a company web site. By simulating a user's experience,the owner of a web site can determine the integrity of links andresources in the page and rate a customer's experience against theoperational goals defined by the business. Furthermore, the informationtechnology departments of companies will be better able to track andmeasure critical web resources.

One way to simulate a user's path through a web site is to record allthe requests made by a user at a proxy server, record additional datarelated to each request and open a socket to send back the exact datathat was passed. This technique can be used for web sites that containonly static pages. However, an increasing number of web sites aredynamic, and a method for replaying a user's path through the web mustbe able to account for content such as session IDs and forms. Becausedynamic content can cause a web page session to expire or change overtime, simply replaying a series of requests will often result in errorsbeing returned from the target web site.

Current methods for simulating a path through web sites do notadequately address dynamic web sites. Microsoft Web Stress Analyzer Toolwas developed to stress test a web site prior to making the siteavailable on the Internet. The Microsoft tool only supports cookie-baseddynamic web site techniques but does not support other techniques, nordoes it support HTTPS communication between a browser and a web site.Furthermore, the Microsoft tool requires that software be downloaded andinstalled on a user's computer.

SUMMARY OF THE INVENTION

The present invention provides a web path replay system and method thatsubstantially eliminates or reduces disadvantages and problemsassociated with previously developed web path replay systems. Morespecifically, the present invention provides a system and method forreplaying a predefined path through a set of web pages. The method forreplaying a predefined web path includes selecting a saved requestassociated with a saved URL from a request history. If the saved requestis a form request, the present invention can determine a best-fit formfrom the originating web page for which a replay request can be made.Alternatively, if the request is not a form request, the presentinvention selects a best-fit URL on the originating web page for which areplay request can be made. After a best-fit form or a best-fit URL isselected as a target URL, the present invention makes a replay requestto the target URL.

The present invention provides substantial advantages over previouslydeveloped systems by allowing a path through a dynamic web page to bereplayed.

The present invention provides yet another important technical advantageby being completely web based.

The present invention provides yet another important technical advantageby running on industry standard servers.

The present invention provides yet another important technical advantageby supporting HTTPS communications.

The present invention provides yet another important technical advantagebecause it does not require the user to install additional software on auser's computer.

The present invention provides a significant advantage by being able toreplay a path through a substantially larger number of web pages thanpreviously developed methods.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptiontaken in conjunction with the accompanying drawings in which likereference numerals indicate like features and wherein:

FIG. 1 is a diagrammatic representation of a system in which the presentinvention can record and replay a path; and

FIG. 2 is a flow chart illustrating one embodiment of the presentinvention for replaying a path through a set of web pages.

DETAILED DESCRIPTION OF THE INVENTION

Preferred embodiments of the present invention are illustrated in theFIGUREs, like numerals being used to refer to like and correspondingparts of the various drawings.

For the purposes of the present invention, “content” refers to the HTMLand other data returned to a user's browser by a web page in response touser's commands (e.g., when the user selects a link). “Static” contentis that content returned to a user's browser which does not change overtime. A “dynamic” web page represents a page that can contain different,non-preformatted content that changes over time in response to the sameuser's commands. A “path” is a succession of web requests in aparticular order.

The present invention provides a system for replaying a user's paththrough the web from an intermediate server. FIG. 1 is a diagrammaticrepresentation of a system in which the present invention can beimplemented for recording and replaying a user's path through the web. Auser can access software program 5 at intermediate server 10 via webbrowser 20. In one embodiment, the user, after accessing softwareprogram 5 at intermediate server 10, can use web browser 20 to provide apathname (“path 1”) and a starting URL to software program 5. The pathname and starting URL can be saved in database 15. The path name is usedto categorize a particular path defined by the user, while the startingURL is the starting point of the user's path. Once the user indicatesthey are ready to begin defining a path by clicking on a “start” button,for example, software program 5 can then cause a display window to openin web browser 20. The display window is a new window in web browser 20in which the content received in response to a user's commands will bedisplayed. Web browser 20 sends the request for the starting URL tosoftware program 5 and software program 5, after saving the request indatabase 15, forwards the request to target web server 30. Target webserver 30 will then return the content corresponding to web page 35,which is associated with the URL in the request, to intermediate server10. Software program 5 can then mediate the content so that anyadditional requests made by a user from the content of web page 35 willbe routed through intermediate server 10. Mediation of the content of aweb page can be done according to the method disclosed in patentapplication Ser. No. 09/710,214, entitled “A System and Method ofMediating a Web Page” by inventors Clay Davis, Walter Bodwell andMichael Klobe, filed on Nov. 10, 2000, which is hereby incorporated byreference in its entirety.

Software program 5, after mediating the content, can then communicatethe mediated content to the display window of web browser 20. From auser's perspective, the page displayed in the display window of webbrowser 20 can look identical to the view which would have beendisplayed had web the user accessed target web server 30 directly.However, the display window of web browser 20 may have been openedwithout navigation or status bars. This may have been done so that auser will not inadvertently circumvent the path defining process bydirectly entering a URL at the top of the web browser 20 rather thanaccessing URLs through the mediated content displayed in the displaywindow.

As the user makes an additional request for new web page 36 (e.g. a“target web page 36”), web page 35 becomes the “originating page 35.”Target web page 36 may be associated with the same target web server 30as originating page 35 or a different target web server 30. Againsoftware program 5 will mediate the contents of target web page 36 inresponse to the additional request and return the mediated contents tobrowser 20. It should be understood that both originating page 35 andtarget web page 36 are mediated. If the user makes an additional requestfrom target web page 36, target web page 36 will be equivalent tooriginating page 35 for yet another target web page 36, and so on. As anexample, if the “page A” was associated with the starting URL, and theuser made a request for “page B” based on the mediated contents of “pageA,” “page A” would be originating web page 35 for target “page B.”Software program 5 would mediate the contents of “page B” and forwardthe mediated contents to web browser 20. If the user made an additionalrequest for “page C” from “page B”, “page B” would be originating page35 for target “page C.” “Page A,” “Page B” and “Page C” may beassociated with the same web server, or each may be associated with adifferent web server. As the user enters an additional request based onthe content displayed in the display window of web browser, softwareprogram 5 saves the additional request in database 15.

In addition to saving requests to database 15, software program 5 canalso record content such as cookies, headers and form parameters sentwith the user request or returned in the content of web page 35. In thismanner, intermediate server 10 can build a request history that containsinformation corresponding to each request made by a user. Generally,software program 5 can save all interactions to database 15 that requirea server's intervention as a “request history” for that path. When theuser is done defining a path through the web, the user can stop the pathdefining process, and the path is saved under the path name provided bythe user.

During the replay process of the present invention, software program 5accesses the request history stored at database 15 and sends out therequests in the order they were originally made. Furthermore, softwareprogram 5 will send the appropriate headers, cookies and/or formparameters necessary for a particular web page. Target web server 30will return the appropriate content of target web page 36, whichcorresponds to each request. For each additional request, target webpage 36 for the previous request will become originating page 35 for thenext replay request. Software program 5 will continue to send outrequests from the request history until the path defined by the user isfully replayed.

FIG. 2 is a flow chart showing one embodiment for replaying a predefinedpath through a set of web pages according to the present invention. Atstep 60, software program 5 can access the request history from database15 containing such information as the starting URL, additional requests,headers, cookies, whether a form request was a POST or a GET, addressesof URLs within the content of originating page 35 and form parameters.During the first iteration of the present invention, the requestcorresponds to the starting URL of the user's path. Because the firstrequest is made to the starting URL, program 5 will generally not haveto send information corresponding to dynamic content. However, theadditional requests may require that software program 5 send informationthat is dynamic in nature. From the request history stored on database15, software program 5, at step 70, selects a saved request. The savedrequests are generally selected in chronological order so that theuser's path may be properly replayed.

After a particular saved request has been selected, software program 5,at step 80, can determine whether the saved request is a form request. Aparticular URL request can be distinguished as a form request because,in the request history stored on database 15 the URL could have beennoted to be associated with a “FORM” tag. If such an association is notfound, then the request will not be for a form. As shown in FIG. 2, ifthe saved request is a form request, the present invention performssteps 90 and 100 prior to performing step 120. If the saved request isnot a form request, the present invention performs step 110 prior toperforming step 120.

If the saved request is a form request, at step 90, software program 5can determine to which form a replay request should be later made.Determining the form to which a replay request should be made can bemuch more involved than simply sending a replay request to the URL inthe saved request. It is possible that the “current configuration,” thatis the configuration encountered when the path is replayed, oforiginating form 35 may be different than the configuration when theuser originally defined the path. Furthermore, the current configurationof originating page 35 may contain more than one form to which a replayrequest can be made, and can even contain multiple forms sharing acommon URL. In order to account for these difficulties, softwareprogram, at step 90, selects a best-fit form from the potential formslocated on the current configuration of originating page 35.

The method for selecting a best-fit form depends on the form parametersthat were saved when the user originally defined a path. Form parameterscan be generated in several ways. First, the user will generate formparameters when they originally fill in the form. Second, formparameters can be created or modified by web browser 20 throughJavaScript, based on the user's entries. Finally, form parameters can beincluded in the form itself with values generated by target web server30. Form parameters generated by JavaScript or included in the formitself are often hidden from the user. The saved form parameterscorresponding to a saved request will generally include form parametersfilled in by the user. However, if web browser 20 replaces or changes auser submitted form parameter with a JavaScript-generated formparameter, the JavaScript-generated form parameter will be saved in therequest history rather than the user-submitted form parameter. Forexample, if a user clicked on a check box, but JavaScript changed thisto a “1,” the replay request will only include the “1” when the path isreplayed, and not an operation for checking the box. This is donebecause intermediate server 10 need only submit the parameters that willgenerate the appropriate response from target web server 30.

If the saved request is a form request, at step 90, software program 5reads the tags in originating page 35 to determine if any forms matchthe URL in saved request. Any forms that do not include a matching URLare rejected. The order of steps for filtering out remaining forms onweb page 35 depends on whether the saved request is a “POST” or a “GET.”Software program 5 can distinguish a “POST” from a “GET” because thecategory of a form request was saved in the request history when theuser originally defined the path. If the saved request is for a POST,every form in originating page 35 is rejected that does not require allthe parameters that are saved in the request history and would beincluded in a replay request. For example, if a “name” parameter isassociated in the request history with a saved request, every form onoriginating page 35 which does not require the “name” parameter will berejected. If more than one potential form still remains on theoriginating web page, the present invention will reject all forms on webpage 35 which do not contain all the hidden parameters saved in therequest history for the saved request. If there is still more than onepotential form left after these initial filtering processes, a form ischosen in a predetermined manner. For example, the first remaining formon the page could be chosen or a random remaining form could be chosen.It should be understood that any predetermined selection method could beused to select the best-fit form from the remaining eligible forms.

If the request is a GET, the first-pass filter of rejecting any formswhich do not match the URL in saved request is the same as when the formrequest is a POST. However, the second and third-pass filters aretransposed. With a GET, as opposed to a POST, software program 5 firstrejects all forms which do not contain all the hidden parameters savedin the request history for the saved request. If more than one potentialform remains on web page 35, the present invention will reject all formsthat do not contain all the parameters saved in the request history thatwould be included in a replay request. As noted in conjunction with thePOST request, forms on originating page 35 may not require all theparameters saved in the request history. If there is still more than onepotential form left after the initial filters are applied, a form ischosen in a predetermined manner, as with a POST request. For example,the first remaining form on the page could be chosen or a randomremaining form could be chosen. Again, it would be understood that anymanner of selecting a form from the eligible forms could be used.

After determining to which form a request should be associated, softwareprogram 5, at step 100, can merge parameters from the parameters savedin the request history with parameters that appear on the form in thecurrent configuration of web page 35. Software program 5 can determinewhich parameters to include in the replay form parameters by comparinghow the form parameters were generated. If the user entered a formparameter, the parameter will be included in the replay form parameters,unless, as described above, the parameter was modified by JavaScript. Ifthe form parameter was modified or generated by JavaScript at webbrowser 20, the JavaScript-generated parameter would be included in thereplay form parameters rather than the user entered parameter. If a formparameter was submitted when the user made the original request, but theparameter was not entered by the user or generated by JavaScript,software program 5 will assume the parameter was included in the formitself. Software program 5 will then replace the form parameteroriginally saved in the request history with the form parameter providedin the form for the current configuration of the originating web page.As an example, a form in originating 35 may have included a session IDwhen the path was originally defined. If the replay request includes theform parameter saved in the request history, errors will likely resultwhen the replay request is made. The errors may cause a “sessionexpired” message to be returned to software program 5 and the user'spath will not be properly simulated. Therefore, software program 5 willreplace the session ID stored in the request history with the session IDcontained in the form for the current configuration of web page 35,thereby preventing an expiration error. In this manner, software program5 can place the appropriate content into updated form fields (such assession IDs, timestamps, etc).

If, at step 80, the software program 5 determines that a saved requestis not a form request, software program 5, at step 110, determines whichURL link in web page 35 is a best-fit for the URL in the saved request.If the exact URL from the saved request is found in a link on web page35, this exact URL is used in the next request. If the exact URL can notbe found, the present invention determines if a nonmatching URL can befound at the address on web page 35 that corresponds to the address ofthe URL in the original URL request.

An “address”, in this context, refers to the place on web page 30 atwhich a saved request was originally found. When a user defined a path,software program 5, could assign a web page address to each URLrequested. The addresses can be assigned based on the structure of tagsand attributes in web page 35. For example, given the following page:

<html> <head> <base href=http://www.company.com/server/home.html><title>Server</title> </head> <body> <a href=first.html>Click HereFirst</a> <a href=http://www.company.com/next.html>Click Here Next</a></body> </html>

The root of the structured page is an <html> tag. This tag contains twotags a <head> and a <body> tag. The <head> tag contains a <title> tag,and so on. This structure allows an individual attribute value on a HTMLpage to be assigned an address. For instance, the address of the <a>with the text “Click Here Next” is “html[0].body[0].a[1].href[0]”. Thisaddress identifies the exact location of a tag or attribute on web page35. If the exact URL from the saved request is not found on web page 35,then the URL at the corresponding address will be used. For example, ifthe user clicked on “Click Here Next” when defining a path web page 35,but the corresponding URL http://www.company.com/next.html could not befound, the replay request would be made to a URL located at the addressof “html[0].body[0].a[1].href[0]” in web page 35. It would be understoodthat alternative forms of addressing can be used which yield a locationwithin the HTML of web page 35.

Alternatively, if the exact URL in the saved request can not be found inweb page 35, software program 5 can match a partial URL. For example, apartial URL match can include matching a somewhat different URL to theURL in a saved request based on the number of characters that matchbetween the URLs.

Software program 5 can also match a URL when web browser 20, throughJavaScript, modified a URL originally found in web page 35. For example,if JavaScript appended a string to a URL when the original request wasmade to the URL, the request with the appended string would be stored inthe request history. However, when software program 5 parses the currentconfiguration of web page 35 for the exact URL used in the saved requestduring replay, the URL will not be found because the string will not bepresent in web page 35. Software program 5 can append the string savedin the request history to the URL found at the address in web page 35where the URL of the saved request was originally found.

In summary, at step 110, software program 5 can find a best-fit URL inseveral ways. Software program 5 can use an exact or partial match toselect a best fit URL in the current configuration of web page 35.Software program 5 can also use a system of addresses in order to selecta best-fit URL. Software program 5 may also use a combination of partialmatching and addresses to select a best-fit URL, particularly when theURL in the saved request is the result of modification by JavaScript.

As shown in FIG. 2, after selecting the best-fit URL (step 110) orselecting and populating the best fit form (steps 90 and 100) softwareprogram 5, at step 120, can optionally add the appropriate headers to areplay request. Many web pages are browser dependent; that is, theyreturn different data depending on the type of browser used. In order toaccurately simulate a user's path, software program 5 sends the headersstored in the request history so that the responding web page willreturn the same content as if the replay request were made from theuser's browser. Furthermore, if target web page 36 requires userauthentication, e.g. by returning status code 401, the present inventioncan return a request with an authentication header. Since the simulationof the user does not involve an actual user, there is no reason toaccess the authentication window for target web page 36, and this windowcan be bypassed.

At step 130, software program 5 can determine whether cookies should bereturned to target web page 36 based on the creation details of thecookie. Also, software program 5 can modify cookies so that target webpage 36 will not return expiration errors. For example, if the useroriginally visited a web page on March 3, and a cookie was returned thathad a one day expiration, the current invention could modify the cookieso that the date returned in the cookie was the current date of the pathreplay, say October 17, with a one day expiration. The date can bemodified because software program 5 stored the creation details of thecookie in database 15 when the path was defined. Because softwareprogram 5 can modify cookies so that target web page 36 will not returnerrors, a user's path can be replayed through dynamic web pages atsubsequent times.

After determining the appropriate target web page 36 and the data to beincluded, software program 5, at step 140, can make the replay request.The replay request simulates the commands that would be made by a userin order to replay the path previously defined by the user. After makingthe replay request to target web server 30, software program 5determines whether or not target web server 30 responded to the replayrequest. If target web server 30 responded, the current configuration oftarget web page 36 that was returned will be used as originating page 35for the subsequent request in the request history. Target web server 30could, alternatively, not respond or return an error. Software program 5may receive a “time out error” or a “page not found” error indicatingthat either the appropriate target web server 30 or target web page 36was not found. If an error of this nature is received by softwareprogram 5, software program 5, at step 160, can notify the user of theerror via e-mail, or other means, and terminate the playback process. Iftarget web server 30 responds with target web page 36, software program5, at step 170, can repeat steps 60-160 of the present invention foreach saved request in the request history, thereby replaying the pathoriginally defined by the user.

The present invention provides a system and method for replaying apredefined path that allows a path through both static and dynamic webpages to be simulated. This allows the present invention to be appliedto a much greater number of web pages than previously developed methodsfor replaying paths through a web page.

The present invention has been described in detail, it should beunderstood that various changes, substitutions and alterations can bemade hereto without departing from the spirit and scope of the inventionas described in the appended claims.

1. A method for replaying a predefined path through a set of web pagescomprising: selecting a saved request corresponding to a saved URL froma request history stored at an intermediate server computer; if thesaved request is a form request, selecting a best-fit form from a set offorms in an originating web page as a target URL; if the saved requestis not the form request, selecting a best-fit URL in the originating webpage as the target URL; and sending a replay request to the target URL.2. The method of claim 1, wherein the replay request includes a set ofreplay form parameters.
 3. The method of claim 2, wherein the set ofreplay form parameters comprises: a set of saved form parameters; and aset of merged form parameters, wherein the set of merged form parametersincludes from the current configuration of the originating web page. 4.The method of claim 1, selecting a best-fit URL further comprises: ifthe URL of a link exactly matches the saved URL, selecting the link asthe best-fit URL; if the URL of the link does not exactly match savedURL, selecting a nonmatching URL located at an address associated withthe saved request as the best-fit URL.
 5. The method of claim 4, furthercomprising, if the nonmatching URL partially matches the saved URL,selecting the nonmatching URL as the best-fit URL.
 6. The method ofclaim 5, further comprising appending a string contained in the savedrequest to the nonmatching URL to form the URL for the replay request.7. The method of claim 1, wherein the replay request includes a set ofheaders so that a target web page returns the same contents as if thereplay request were made from a particular type of browser.
 8. Themethod of claim 1, wherein the replay request includes a set of cookies,and the set of cookies contains a modified cookie corresponding to asaved cookie, wherein the modified cookie has been modified such that atarget web page returns content as if the replay request were made by anew user.
 9. The method of claim 1, further comprising determiningwhether the saved request is a POST or a GET.
 10. A method for replayinga predefined path through a set of web pages comprising: (a) selecting asaved request corresponding to a saved URL from a request history storedat an intermediate server computer; (b) if the saved request is a formrequest, selecting a best-fit form from a set of forms in a originatingweb page as a target URL; (c) if the saved request is not the formrequest, selecting a best-fit URL in the originating web page as thetarget URL; (d) sending a replay request to the target URL; and (e)repeating steps (a) through (e) until each saved request from therequest history has been replayed.
 11. A system for replaying apredefined path through a set of web pages comprising: a computerreadable medium; and a set of software instructions stored on thecomputer readable medium operable to cause a computer to: select a savedrequest corresponding to a saved URL from a request history if the savedrequest is a form request, select a best-fit form from a set of forms ina originating web page as a target URL; and if the saved request is notthe form request, select a best-fit URL in the originating web page asthe target URL; and send a replay request to the target URL.
 12. Thesystem of claim 11, wherein the replay request includes a set of replayform parameters.
 13. The system of claim 12, wherein the set of replayform parameters includes: a set of saved form parameters; and a set ofmerged form parameters, wherein the set of merged form parametersincludes parameters from the current configuration of the originatingweb.
 14. The system of claim 11, wherein the software instructions arefurther operable to select a best-fit URL by: if the URL of a linkexactly matches the saved URL, selecting the link as the best-fit URL;if the URL of the link does not exactly match saved URL, selecting anonmatching URL located at an address associated with the saved requestas the best-fit URL.
 15. The system of claim 14, wherein the softwareinstructions are further operable to select a best-fit URL by: selectingthe nonmatching URL as the best-fit URL if the nonmatching URL partiallymatches the saved URL.
 16. The system of claim 15, wherein the softwareinstructions are further operable to cause a computer to append a stringcontained in the saved URL to the nonmatching URL in order to form theURL in the replay request.
 17. The system of claim 11, wherein thereplay request includes a set of headers so that a target web pagereturns the same contents as if the replay request were made from aparticular type of browser.
 18. The system of claim 11, wherein thereplay request includes a set of cookies, and the set of cookiescontains a modified cookie corresponding to a saved cookie, wherein themodified cookie has been modified such that a target web page returnscontent as if the replay request was made by a new user.
 19. The systemof claim 11, wherein the software program is further operable todetermine whether a saved request is a POST or a GET.
 20. A system forreplaying a predefined path through a set of web pages comprising: anintermediate server including: a computer readable medium; a computerprocessor; and a database; and a set of software instructions stored onthe computer readable medium such that the computer processor isoperable to: select a saved request corresponding to a saved URL from arequest history, wherein the request history is stored on the database;if the saved request is a starting URL request, select a starting URL asa target URL; if the saved request is the form request, select abest-fit form from a set of forms in a originating web page as thetarget URL; if the saved request is not the form request, select abest-URL in the originating web page as the URL and; send a replayrequest to the target URL.
 21. The system of claim 20, wherein thereplay request includes a set of headers so that a target web pagereturns the same contents as if the replay request were made from aparticular type of browser.
 22. The method of claim 21, wherein thereplay request includes a set of cookies, and the set of cookiescontains a modified cookie corresponding to a saved cookie, wherein themodified cookie has been modified such that a target web page returnscontent as if the replay request were made by a new user.
 23. A methodfor creating a path through a set of web pages and replaying the pathcomprising: saving a path, wherein saving a path further comprises;receiving a first user request for an originating web page; saving thefirst user request in a request history at an intermediate server;forwarding the first user request to a target web server; receiving theoriginating web page from the target web server; mediating theoriginating web page to refer to an intermediate server; forwarding theoriginating web page to the user; receiving an additional user requestfor a target web page, wherein the additional user request is based onthe mediated content of the originating web page; and recording theadditional user request in the request history; and replaying a path,wherein replaying a path further comprises: selecting a saved requestfrom the request history; if the saved request corresponds to a startingURL, selecting the starting URL as the target URL; if the saved requestis a form request, selecting a best-fit form from a currentconfiguration of the originating web page as the target URL; if thesaved request is not a form request, selecting a best-fit URL from thecurrent configuration of the originating as the target URL; and making areplay request to the target URL.
 24. A method for replaying apredefined path through a set of web pages comprising: selecting a savedrequest corresponding to a saved URL from a request history stored at anintermediate server computer; if the saved request is a form request,selecting a best-fit form from a set of forms in an originating web pageas a target URL; if the saved request is not the form request, selectinga best-fit URL in the originating web page as the target URL; andsending a replay request to the target URL.